Skip to content

Helpful errors for Ultralytics names, imports and checkpoints - #1032

Merged
EHxuban11 merged 3 commits into
devfrom
feat/ultralytics-name-hints
Nov 11, 2026
Merged

EHxuban11 merged 3 commits into
devfrom
feat/ultralytics-name-hints

Conversation

@EHxuban11

@EHxuban11 EHxuban11 commented Nov 11, 2026 •

Copy link
Copy Markdown
Contributor

Newcomers and coding agents often arrive with Ultralytics habits and hit dead ends with no hint of what to type instead. This turns the most common ones into errors that name the LibreYOLO equivalent.

Changes

  • from libreyolo import YOLO (also RTDETR, NAS, YOLOWorld, YOLOE, SAM) raises an ImportError that shows the LibreYOLO import and a one-line example. Plain attribute access still raises AttributeError, so hasattr() is unchanged.
  • Ultralytics weight names (yolov8n.pt, yolo11s-seg.pt, v3u/v5/v8/v9/v10/11/12/26, -seg/-pose/-obb/-cls/-world, yoloe-*, yolo_nas_*, model .yaml, misspellings like yolov11n) now say it is an Ultralytics name, that LibreYOLO does not load Ultralytics weights, and suggest the closest LibreYOLO model. Every suggested file is checked against the model registry in tests.
  • Ultralytics-trained checkpoints (best.pt) are detected without unpickling and refused with a "train a LibreYOLO model on your data" hint, instead of torch's weights_only=False advice.
  • Same hints in the CLI (predict, train, val, export, quantize, info).
  • predict() options project, name, tracker, persist, save_txt, save_conf name the LibreYOLO equivalent.
  • Fix: LibreYOLO("yolov8n") no longer suggests a nonexistent hf://weights/yolov8n path.

No Ultralytics name becomes an alias, and nothing loads or converts Ultralytics weights.

Tests

tests/unit/test_ultralytics_hints.py (about 60 cases) plus a torch-free import test. Locally with pytest -n 4: new tests, tests/unit/cli and related loading tests pass.

Code provenance

Original code written for this PR. No code ported or adapted from other repositories.

RetriggerView in GreptileConfidence Score: 5/5

The PR appears safe to merge, with a non-blocking correction needed in the classification training hint.

Fix All in CursorFindings

  1. P2 Classification hint suggests unsupported YAML ▶

Summary

Adds errors that show LibreYOLO alternatives for unsupported Ultralytics imports, model names, checkpoints, and prediction options.

  • Python imports of Ultralytics class names now show the LibreYOLO import.
  • Ultralytics model names now point to the closest LibreYOLO model or training command.
  • Ultralytics checkpoints now explain how to train with LibreYOLO instead.
  • Unsupported prediction options now name the LibreYOLO way to do the same job.

Reviews (3) · Last reviewed commit: "Untrained-model hints train with pretrai..." · Reviewed by Greptile

from libreyolo import YOLO, Ultralytics weight names, Ultralytics-trained
checkpoints, CLI model names and predict options now fail with the
LibreYOLO line to type instead. No aliases; Ultralytics checkpoints never
reach the autoconverter.
Comment thread libreyolo/utils/ultralytics_hints.py Resolved
Comment thread libreyolo/cli/command_utils.py Resolved
Comment thread libreyolo/utils/ultralytics_hints.py Resolved
Read only <archive>/data.pkl, capped at 4 MiB, when checking for an
Ultralytics checkpoint. Task YAML names (-seg, -pose, -obb, -cls) now
suggest an untrained model like detection YAMLs do. The CLI only adds
pretrained=False under train; other commands get a full train command.
Comment thread libreyolo/utils/ultralytics_hints.py Resolved
@EHxuban11
EHxuban11 merged commit ed1b76b into dev Nov 11, 2026
12 of 13 checks passed
f'model = {cls_name}(None, size="{s}"{task_arg}); '
# pretrained=False rebuilds the model for scratch training (some
# families freeze parts of a randomly initialised network otherwise).
f'model.train(data="your_data.yaml", pretrained=False)',

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Classification hint suggests unsupported YAML

For classification names such as yolov8m-cls.yaml, the new training step suggests data="your_data.yaml". But LibreMobileNetV4.train() accepts a dataset directory, a known dataset name, or a ZIP URL, not a dataset YAML file. Users who substitute their own YAML file get another error instead of starting training. Use a classification dataset directory in this hint.

Fix in Cursor Fix in Codex

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant